Translation tables are used in computing systems to provide an interface between a device, such as an Input/Output (I/O) device, and the central core of the computing system. For example, an I/O device may be assigned a set of virtual addresses it may use for accessing resources provided by the computing system. The virtual addresses are independent of the actual, physical memory locations of the resources in the computing system. In such a manner, the I/O device does not need to be updated any time there is a change within the computing system. Instead, when the I/O device requests to access a particular resource, it simply presents the assigned virtual address in its request. An I/O Memory Management Unit (IOMMU) receives the request from the I/O device and translates the virtual address into the physical memory location of the resource.
To accomplish this task, the IOMMU uses one or more address translation tables. An address translation table stores entries that provide a location of a physical memory page. The tables are indexed using high-order bits of the virtual address from the I/O device. Thus, when the request to access a system resource is received, the IOMMU can access the appropriate entry in the address translation table to complete the request. Address translation tables are maintained by a processor of the computer system. That is, the processor has read and write access to the translation table, while the IOMMU and any other devices that use the table, if present, have only read access.
Address translation tables can be very large, and are typically constructed as a series of tables arranged in a tree format. In this tree format, an entry in a table may point to another table, which in turn may point to another table, and so on, until a “leaf” level is reached. The leaf level is the point in the tree at which the appropriate physical memory location, or a pointer to the location, is stored. The process of following these pointers to the leaf level, called “walking” the tree, takes up valuable processing time due to the complexity involved with the process of walking through all of the necessary levels of the tree to reach the appropriate leaf level, particularly if the table is very large. Because some physical memory locations are accessed repeatedly, a cache is typically used to store entries for such frequently-accessed locations. Thus, upon receiving an I/O device request to access a computer resource, the IOMMU first checks the cache to determine whether an entry corresponding to the requested virtual address is present. If the entry is present, the IOMMU acquires the physical memory location from the cache entry, thereby avoiding walking the tree. If the entry is not present, the IOMMU walks the tree to find the appropriate entry and, upon finding the entry, uses the physical address to complete the access and may also create a cache entry to avoid walking the tree in the future.
Sometimes the physical memory location that is associated with virtual address is changed. In such a situation, the address translation table entry that associates the virtual address with the old physical memory location is changed to point to the new physical memory location. Because, conventionally, the processor is the only component that is permitted to write to an address translation table, the processor makes the change to the appropriate entry. If the entry has been stored in a cache, the processor generates a message containing a virtual address or a range of virtual addresses corresponding to the entry to the IOMMU, and an indication that the cache entry must be deleted. The IOMMU then flushes the indicated entry from the cache. When a request is subsequently received for the virtual address, the IOMMU will check the cache, find that the entry is not present, and then walk the address translation table to find the entry. The IOMMU may also save the new entry to the cache.
There are several shortcomings associated with the conventional mechanism for handling address translation tables. For example, because the IOMMU is only able to read from an address translation table, the information the IOMMU is able to provide to other components is limited to that which is provided by the processor. In some situations, it may be useful to store additional information in the address translation table that the IOMMU could use for performance tracking and other purposes. Because the processor maintains the tables, however, the IOMMU is not able to do this because the processor and the IOMMU are not in the same coherency domain. That is, any changes made by the IOMMU could result in a conflict with those made by the processor, which could cause serious faults in the system. Having the processor maintain such additional information would unduly burden the processor with additional workload and adversely affect system performance.
In addition, the conventional update mechanism is inefficient. For example, when the processor sends a message to the IOMMU indicating that a cache entry has been changed, the processor only provides sufficient information for the IOMMU to delete the cache entry. The IOMMU must then walk through the address translation table the next time the virtual address associated with the entry is presented, which is time consuming. In addition, if a cache entry of the new address is desired, the IOMMU must create a new cache entry in an operation that is separate from the cache entry delete operation.